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(54) Conditional garbage collection based on monitoring to improve real time performance 



(57) A system comprising a counter adapted to 
monitor the memory consumption of the allocated mem- 
ory resources. Upon reaching or surpassing the mem- 
ory resource threshold provided, the counter may indi- 
cate the need for garbage collection. The garbage col- 
lector assesses the memory and releases memory re- 
sources that are consumed by the programs but are not 
needed anymore. The recycled memory resources are 



thus provided to the programs and the counter is updat- 
ed accordingly. In addition, the system may also include 
instructions requesting memory resources. After detect- 
ing such instructions, the memory usage counter is up- 
dated either by the exact amount of memory allocated 
or the estimated amount of memory allocated. The 
counter may be implemented in hardware or in software. 
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Description 

[0001] The present invention relates generally to ex- 
ecuting programs and more particularly, to improve the 
utilization of memory resources by executing a garbage 
collector. 

[0002] Many types of electronic devices are battery 
operated and thus preferably consume as little power 
as possible. An example is a cellular telephone. Further, 
it may be desirable to implement various types of mul- 
timedia functionality in an electronic device such as a 
cell phone. Examples of mu Itimedia functionality may in- 
clude, without limitation, games, audio decoders, digital 
cameras, etc. It is thus desirable to implement such 
functionality in an electronic device in a way that, all else 
being equal, is fast, consumes as little power as possible 
and requires as little memory as possible. Improve- 
ments in this area are desirable. 

BRIEF SUMMARY OF THE PREFERRED 
EMBODIMENTS 

[0003] As disclosed herein, a system (e.g., a cellular 
telephone) comprises a counter capable of monitoring 
the usage of memory resources for program execution. 
The counter monitors the usage of the allocated space 
and a garbage collector execution is conditioned upon 
reaching or surpassing a threshold value for the cou nter. 
The garbage collector eval uates the state of the memory 
and frees memory that has been consumed by pro- 
grams and is not needed anymore. 
[0004] The system includes a processor that decodes 
instructions (e.g., standard Java instructions) some of 
which cause memory request allocation, but may not in- 
dicate how much memory is precisely needed directly 
in the instruction. In this case the decoder may provide 
information to increment a counter, preferably in hard- 
ware, that may indicate the number of memory alloca- 
tions instead the exact amount of memory used. 
[0005] The system may also include a micro-se- 
quence or a software task that replaces Instructions that 
request memory resources. During the execution of the 
micro-sequence or the software task, the counter is up- 
dated with the precise memory amount requested, and 
will increment as the memory is consumed. 
[0006] When the counter reaches a pre-determined 
threshold value, either an interruption is generated to 
signal the need for garbage collection or the JVM or any 
software task that would initiate the garbage collector 
task may check the counter periodically to decide when 
to start garbage collection. The garbage collector frees 
unused memory and updates the memory use counter 
accordingly. The counter may be implemented in soft- 
ware or in hardware. 

NOTATION AND NOMENCLATURE 

[0007] Certain terms are used throughout the follow- 



ing description and claims to refer to particular system 
components. As one skilled in the art will appreciate, 
various companies may refer to a component by differ- 
ent names. This document does not intend to distinguish 

5 between components that differ in name but not func- 
tion. In the following discussion and in the claims, the 
terms "including" and "comprising" are used in an open- 
ended fashion, and thus should be interpreted to mean 
"including, but not limited to...". Also, the term "couple" 

10 or "couples" is intended to mean either an indirect or 
direct connection. Th us, if a first device couples to a sec- 
ond device, that connection may be through a direct 
connection, or through an indirect connection via other 
devices and connections. 

15 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0008] For a more detailed description of the preferred 
embodiments of the present invention, reference will 
20 now be made to the accompanying drawings, wherein: 



Figure 1 shows a diagram of a system in accord- 
ance with preferred embodiments of the invention 
and including a Java Stack Machine f JSM") and a 
Main Processor Unit ("MPU"); 
Figure 2 shows a block diagram of the JSM of Fig- 
ure 1 in accordance with preferred embodiments of 
the invention; 

Figure 3 shows various registers used in the JSM 
of Figures 1 and 2; and 

Figure 4 illustrates a block diagram of a system in 
accordance with preferred embodiments of the in- 
vention including a Main Processor Unit ("MPU") 
and a garbage collector. 
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DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

[0009] The following discussion is directed to various 

40 embodiments of the invention. Although one or more of 
these embodiments may be preferred, the embodi- 
ments disclosed should not be interpreted, or otherwise 
used, as limiting the scope of the disclosure, including 
the claims, unless otherwise specified. In addition, one 

45 skilled in the art will understand that the following de- 
scription has broad application, and the discussion of 
any embodiment is meant only to be exemplary of that 
embodiment, and not intended to intimate that the scope 
of the disclosure, including the claims, is limited to that 

so embodiment. 

[001 0] The subject matter disclosed herein is directed 
to a programmable electronic device such as a proces- 
sor. The processor described herein may be particularly 
suited for executing Java™ Bytecodes, or comparable 

55 code. As is well known, Java is particularly suited for 
embedded applications and is a relatively "dense" lan- 
guage meaning that on average, each instruction may 
perform a large number of functions compared to vari- 
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ous other programming languages. The dense nature 
of Java is of particular benefit for portable, battery-op- 
erated devices that preferably include as little memory 
as possible to save space and power. The reason, how- 
ever, for executing Java code is not material to this dis- 
closure or the claims that follow. Further, the embodi- 
ment of the invention may be described in the context 
of Java, but should not be limited to the execution of only 
Java instructions. The processor described herein may 
be used in a wide variety of electronic systems (e.g., cell 
phones). 

[0011] Referring now to Figure 1, a system 100 is 
shown in accordance with a preferred embodiment of 
the invention. As shown, the system includes at least 
two processors 1 02 and 1 04. Processor 1 02 is referred 
to for purposes of this disclosure as a Java Stack Ma- 
chine ("JSM") and processor 1 04 may be referred to as 
a Main Processor Unit ("MPU"). System 100 may also 
include memory 106 coupled to both the JSM 102 and 
MPU 104 and thus accessible by both processors. At 
least a portion of the memory 106 may be shared by 
both processors meaning that both processors may ac- 
cess the same shared memory locations. Further, if de- 
sired, a portion of the memory 1 06 may be designated 
as private to one processor or the other. System 1 00 
also includes a Java Virtual Machine ("JVM") 1 08, com- 
piler 110, and a display 114. The JSM 102 preferably 
includes an interface to one or more input/output ("I/O") 
devices such as a keypad to permit a user to control 
various aspects of the system 100. In addition, data 
streams may be received from the I/O space into the 
JSM 102 to be processed by the JSM 102. Other com- 
ponents (not specifically shown) may be included as 
well. 

[0012] As is generally well known, Java code compris- 
es a plurality of "Bytecodes" 112. Bytecodes 112 may 
be provided to the JVM 108, compiled by compiler 110 
and provided to the JSM 102 and/or MPU 104 for exe- 
cution therein. In accordance with a preferred embodi- 
ment of the invention, the JSM 1 02 may execute at least 
some, and generally most, of the Java Bytecodes. When 
appropriate, however, the JSM 102 may request the 
MPU 104 to execute one or more Java Bytecodes not 
executed or executable by the JSM 102. In addition to 
executing Java Bytecodes, the MPU 104 also may ex- 
ecute non-Java instructions. The MPU 104 also hosts 
an operating system ("O/S") (not specifically shown), 
which performs various functions including system 
memory management, the system task management 
that schedules the JVM 1 08 and most or all other native 
tasks running on the system, management of the display 
114, receiving input from input devices, etc. Without lim- 
itation, Java code may be used to perform any one of a 
variety of applications including multimedia, games or 
web-based applications in the system 100, while non- 
Java code, which may comprise the O/S and other na- 
tive applications, may still run on the system on the MPU 
104. 



[001 3] The JVM 1 08 generally comprises a combina- 
tion of software and hardware. The software may in- 
clude the compiler 110 and the hardware may include 
the JSM 1 02. The JVM may include a class loader, Byte- 
5 code verifier, garbage collector, and a Bytecode inter- 
preter loop to interpret the Bytecodes that are not exe- 
cuted on the JSM processor 102. 
[0014] In accordance with preferred embodiments of 
the invention, the JSM 1 02 may execute at least two in- 
fo struction sets. One instruction set may comprise stand- 
ard Java Bytecodes. As is well known, Java is a stack- 
based programming language in which instructions gen- 
erally target a stack. For example, an integer add 
flADD") Java instruction pops two integers off the top 

is of the stack, adds them together, and pushes the sum 
back on the stack. In general, the JSM 102 comprises 
a stack-based architecture with various features that ac- 
celerate the execution of stack-based Java code. 
[0015] Another instruction set executed by the JSM 

20 1 02 may include instructions other than standard Java 
instructions. In accordance with at least some embodi- 
ments of the invention, such other instruction set may 
include register-based and memory-based Instructions. 
This other instruction set generally complements the 

25 Java instruction set and, accordingly, may be referred 
to as a complementary instruction set architecture 
("C-ISA") such as those instructions disclosed in one or 
more of the previously listed co-pending applications. 
By complementary, it is meant that at least some Java 

30 Bytecodes may be replaced by micro-sequences using 
C-ISA Instructions that permit address calculation to 
readily "walkthrough" the JVM data structures. A micro- 
sequence may comprise one or more C-ISA instruc- 
tions. Further, such micro-sequences may also include 

35 Java Bytecode instructions. The execution of Java may 
be made more efficient and run faster by replacing some 
sequences of Bytecodes by preferably shorter and more 
efficient sequences of C-ISA instructions. The two sets 
of instructions may be used in a complementary fashion 

to to obtain satisfactory code density and efficiency. As 
such, the JSM 102 generally comprises a stack-based 
architecture for efficient and accelerated execution of 
Java Bytecodes combined with a register-based archi- 
tecture for executing register and memory based C-ISA 

^5 instructions. Both architectures preferably are tightly 
combined and integrated through the C-ISA. 
[0016] Figure 2 shows an exemplary block diagram of 
the JSM 102. As shown, the JSM includes a core 120 
coupled to data storage 1 22 and instruction storage 1 30. 

so The core may include one or more components as 
shown. Such components preferably include a plurality 
of registers 140, three address generation units 
("AGUs") 142, 147, micro-translation lookaside buffers 
(micro-TLBs) 144, 156, a multi-entry micro-stack 146, 

55 an arithmetic logic unit ("ALU") 1 48, a multiplier 1 50, de- 
code logic 152, and instruction fetch logic 154. In gen- 
eral, operands may be retrieved from data storage 122 
or from the micro-stack 1 46, processed by the ALU 1 48, 
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while instructions may be fetched from instruction stor- 
age 130 by fetch logic 154, pre-decoded by predecode 
logic 158, and decoded by decode logic 152. The ad- 
dress generation unit 142 may be used to calculate ad- 
dresses based, at least in part on data contained in the 
registers 140. The AGUs 142 may calculate addresses 
for C-ISA instructions as will be described beiow. The 
AGUs 1 42 may support parallel data accesses for O ISA 
instructions that perform array or other types of process- 
ing. AGU 147 couples to the micro-stack 146 and may 
manage overflow and underflow conditions in the micro- 
stack preferably in parallel. The micro-TLBs 144, 156 
generally perform the function of a cache for the address 
translation and memory protection information bits that 
are preferably under the control of the operating system 
running on the MPU 104. The decode logic 1 52 may be 
adapted to execute both the standard Java instructions 
as well as the C-ISA instructions of the system. 
[0017] Referring now to Figure 3, the registers 140 
may include 1 6 registers designated as R0-R1 5. Regis- 
ters R0-R3, R5, R8-R11 and 

[0018] R13-R14 may be used as general purposes 
("GP") registers usable for any purpose by the program- 
mer. Other registers, and some of the G P registers, may 
be used for specific functions. For example, registers 
R4 and R1 2 may be used to store two program counters. 
Register R4 preferably is used to store the program 
counter ("PC") and register R12 preferably is used to 
store a micro-program counter ("micro-PC 0 ) . In addition 
to use as a GP register, register R5 may be used to store 
the base address of a portion of memory in which Java 
local variables may be stored when used by the current 
Java method. The top of the micro-stack 146 is refer- 
enced in registers R6 and R7. The top of the micro-stack 
has a matching address in external memory pointed to 
by register R6. The values contained in the micro-stack 
are the latest updated values, while their corresponding 
values in external memory may or may not be up to date. 
Register R7 provides the data value stored at the top of 
the micro-stack. 

[001 9] Registers R8 and R9 may also be used to hold 
the address index 0 ("AI0 a ) and address index 1 
( "AH" ) . Register R1 4 may also be used to hold the in- 
direct register index flRI"). Register R15 may be used 
for status and control of the JSM 1 02. JSM 1 02 also may 
have some additional memory mapped registers not 
shown in Figure 2 that includes various control or con- 
figuration information usually set by the MPU 104. The 
counter and threshold described below may be part of 
those registers. 

[00201 Referring again to Figure 2, as noted above, 
the JSM 102 may execute stacfebased instructions and 
thus the JSM includes a hardware-based micro-stack 
146 for storing operands. Unless empty, Java Byte- 
codes pop data from and push data onto the micro-stack 
146. The micro-stack 146 preferably comprises at most 
the top n entries of a larger stack that may be imple- 
mented in data storage 1 22. Although the value of n may 



be vary in different embodiments, in accordance with at 
least some embodiments, the size n of the micro-stack 
may be the top eight entries in the larger, memory-based 
stack. The micro-stack 146 preferably comprises a plu- 
5 rality of gates in the core 1 20 of the JSM 1 02. By imple- 
menting the micro-stack 146 in gates (e.g., registers) in 
the core 120 of the processor 102, access to the data 
contained in the micro-stack 146 is generally very fast, 
although any particular access speed is not a limitation 

10 on this disclosure. 

[0021] The ALU 148 adds, subtracts, and shifts data 
and may be adapted to completely execute instructions 
in less than two cycles. The multiplier 150 may be used 
to multiply two values together in one or more cycles. 

is The instruction fetch logic 1 54 generally fetches instruc- 
tions from instruction storage 130. The decoder 152 
may then decode the instructions. 
[0022] The data storage 1 22 generally comprises da- 
ta cache ("D-cache") 124 and data random access 

20 memory ("D-RAMset") 1 26. Reference may be made to 
copending applications U.S. Serial Nos. 09/591,537 
filed June 9, 2000 (atty docket TI-29884), 09/591 ,656 
filed June 9, 2000 (atty docket TI-29960), and 
09/932,794 filed August 17, 2001 (atty docket Tl- 

25 31351). The stack (excluding the micro-stack 146), ar- 
rays and non-critical data may be stored in the D-cache 
124, while Java local variables, critical data and non- 
Java variables (e.g., C, C++) may be stored in D-RAM 
126. The instruction storage 130 may comprise instruc- 

30 tion RAM H-RAM") 132 and instruction cache ("I- 
cache") 134. The l-RAMset 132 may be used for rela- 
tively complex micro-sequenced Bytecodes or other mi- 
cro-sequences or critical sequences of codes. The I- 
cache 134 may be used to store other types of Java 

35 Bytecode and mixed Java/CISA instructions. 

[0023] As is well known, programs may be executed 
on processors, such as the JSM 102 or the MPU 104, 
where each program is allocated a portion of the mem- 
ory to utilize. Some of the memory Is allocated dynam- 

^o ically duringthe execution of aprogram, others statically 
when the program is launched. Programs that allocate 
memory dynamically preferably free the memory allo- 
cated when they do not require it anymore. For example, 
a program in C may use "malloc( )" and "free( )" library 

45 functions to free up memory allocation not needed by 
the program. In instances where these programs do not 
free the unused memory correctly, memory leaks occur 
and usually cause the system to crash after some time. 
Such events are well known by programmers as a typ- 

50 jcal fatal error in system called "out of memory error". 
Java programmers do not need to worry about memory 
recollection when they write Java programs because the 
memory re-collection in Java is done by a garbage col- 
lection task embedded into the JVM. The garbage col- 

55 lection task is independent from the executed Java pro- 
gram and may monitor the allocated memory that can 
be recycled and put back into the available memory 
space. 
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[0024] The recycled memory may subsequently be 
re-allocated to programs when a new memory allocation 
request occurs through instructions, such as "New" or 
"NewArray" Java Bytecode. Typically, the garbage col- 
lector is a timed operation, where at a certain time inter- 
val, the processor will stall, and the garbage collector is 
initiated to evaluate the usage of memory space. How- 
ever, in some instances, the garbage collector may not 
be needed, and thus causing the processor to unnec- 
essarily stall the current program execution and also do 
unnecessary processing. 

[0025] In a preferred embodiment, the execution of 
the garbage collector 158 may be conditioned upon a 
precise or approximate usage of memory space, thus 
avoiding unnecessary garbage collections. Referring to 
Figure 4, the JSM 102 is coupled to the MPU 104. The 
MPU 1 04 may be coupled to the garbage collector and 
may be adapted to run the garbage collector 1 58 within 
the memory 106. In a preferred embodiment, the JSM 
1 02 may include the memory usage counter 1 68, where 
the memory usage counter 1 68 may be capable of mon- 
itoring the memory consumption for one or more pro- 
grams. More specifically, the memory usage counter 
1 68 may be adapted to increment according to the con- 
sumption of the allocated memory for the programs. The 
counter may be capable of incrementing until reaching 
a programmable threshold value 166, where the pro- 
grammable threshold value 166 is a value indicating the 
allotted memory allocation for a program and thus, may 
vary from program to program. Upon reaching the 
threshold value 166, the memory usage counter 168 
may send a request for garbage collection. In some em- 
bodiments, the JVM may also monitor the counter value 
to decide when to launch the garbage collector 1 58. The 
garbage collector 158 may thus access memory 106 
and free consumed memory space not needed by the 
programs anymore. The amount of "recycled" memory 
space may then be re-allocated to the programs. The 
counter may be decremented accordingly to reflect the 
freed memory space. 

[0026] In Java, specific instructions may request 
memory allocation but these instructions do not encode 
within their respective Bytecode the amount of memory 
requested. Instead the JVM must look for this amount 
within Java data structures (e.g., Java class) before al- 
locating the memory or sending a request to the oper- 
ating system on which the JVM runs. 
[0027] I n a first embodiment, the decoder 1 52, when 
decoding a Java "New" or "NewArray" Bytecode, or any 
of the other Java Bytecode requesting new memory, 
provides a signal to update the hardware-implemented, 
memory usage counter 16fr bjrgr determined value. 
However, since these Bytecodes belonging to the stand- 
ard Java instruction set do not specify the amount of 
memory needed directly, an approximated value is used 
to update the memory usage counter 1 68, while the pre- 
cise memory allocation is done by software by the JVM. 
The approximate value may be one where the memory 



usage counter 168 may count the number of memory 
allocation request rather than the precise amount of 
memory used to initiate the garbage collector. The ap- 
proximate value may be an average value for the object 
s size used by the current program to give a more precise 
indication to the garbage collector or to the task initiating 
the garbage collector. 

[0028] Java Bytecodes, such as "New" Bytecode, 
"NewArray" Bytecode or any other Bytecode requesting 
10 some memory allocation are complex Bytecodes when 
executed by the JSM 102 and may be replaced by a 
micro-sequence. In a second embodiment, the micro- 
sequence, replacing the Java Bytecodes, may be uti- 
lized to precisely update the memory usage counter. 

'5 The micro-sequence may retrieve the exact number of 
bytes required for the memory allocation within a Java 
data structure (e.g. Java class) and consequently may 
update the memory usage counter 168 precisely as a 
part of or before the memory allocation request. 

20 [0029] In either previously described embodiments, 
the value of the memory usage counter 160 may be 
compared to that of a threshold value 166, and upon 
approaching the threshold, the JSM 102 may send to 
the MPU 104 an interrupt signal, which indicates the 

25 need for garbage collection. The MPU 1 04 may then in- 
itiate the garbage collector 158 in the memory 106, 
where the garbage collector may evaluate memory 1 06. 
After freeing consumed memory resources that may not 
be needed, the memory usage memory usage counter 

30 1 68 may be updated. The memory usage counter 1 68 
may now again be used to monitor the memory con- 
sumption and may be incremented as described above. 
[0030] In another embodiment, where the counter is 
updated by software, the software being executed on 

as the JVM 1 08, the MPU 1 04, or a micro-sequence exe- 
cuted on the JSM 102, the memory usage counter may 
also be a value In memory. As such, the garbage collec- 
tor must poll this value instead of receiving an interrupt 
from the memory usage counter, implemented in hard- 

40 ware, and then compare the value to a threshold value. 
As such, the MPU 104 may utilize interface 170 to ac- 
cess the memory counter 168. 
[0031] By utilizing a counter which monitors the mem- 
ory consumption of the programs, the garbage collector 

45 may only be initiated when memory resources are be- 
coming rare and memory re-collection is likely to be 
needed and useful. The preferred embodiments there- 
fore reduce the number of times the garbage collector 
is executed. The power consumption of the overall sys- 

50 tern is reduced as well as the throughput of the proces- 
sor is increased. 

P)032f While the preferred embodiments of the 
present invention have been shown and described, 
modifications thereof can be made by one skilled in the 
55 art without departing from the spirit and teachings of the 
invention. The embodiments described herein are ex- 
emplary only, and are not intended to be limiting. Many 
variations and modifications of the invention disclosed 
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herein are possible and are within the scope of the in- 
vention. 

[0033] Accordingly, the scope of protection is not lim- 
ited by the description set out above. Each and every 
claim is incorporated into the specification as an embod- 
iment of the present invention. 



Claims 

1 . A system, comprising: 
memory device; 

counter coupled to the memory device, wherein 
the counter is adapted to monitor memory con- 
sumption of the memory device for one or more 
programs; 

a plurality of processors coupled to the counter, 
wherein one of the plurality of processors within 
the system is coupled to a garbage collector 
adapted to free a portion of unused memory; 
and 

wherein executing the garbage collector is 
triggered based on a value of the counter. 
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The system of claim 1 , wherein the value is a pro- 
grammable threshold value, and wherein when the 
counter reaches the programmable value, the gar- 
bage collector is triggered. 30 

The system of claim 2, wherein upon reaching the 
programmable threshold value, the counter sends 
an interrupt value to the processor, which executes 
the garbage collector. 35 

The system of claim 2 or claim 3 wherein a software 
process is regularly polling the counter to check if 
the predetermined threshold value has been 
reached, and wherein upon reaching the predeter- *o 
mined threshold value, the garbage collector is trig- 



triggering a garbage collector to free a portion 
of the memory upon surpassing a threshold val- 
ue; and 

updating a memory usage counter after retriev- 
ing a portion of the memory. 

8. The method of claim 7, wherein the method further 
comprises decoding an instruction requesting 
memory allocation. 

9. The method of claim 8, wherein the instruction is a 
standard Java instruction, and wherein the counter 
is updated with an estimated memory usage value 
for the instruction. 

10. The method of claim 8 or claim 9, wherein the in- 
struction belongs to a micro-sequence, and wherein 
the counter is update with an exact memory usage 
value for the instruction. 

1 1 . The method of any of claims 7-1 0, wherein the step 
of triggering the garbage col lector further comprises 
periodic monitoring of the memory usage counter. 

12. The method of any of claims 7-11 , where the step 
of triggering the garbage collector comprises re- 
ceiving a request from memory usage counter when 
the step of monitoring the memory consumption 
reaches a programmable threshold value. 



The system of any preceding claim, wherein the 
system further comprises a micro-sequence replac- 
ing an instruction requesting memory allocation, 
wherein upon executing an instruction from the mi- 
cro-sequence requesting memory allocation, the 
counter is updated with an exact memory usage val- 
ue for the instruction. 
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6. The system of claim 5, whereto the counter is up- 
dated by a value stored within the memory device. 

7. A method, comprising: 

monitoring memory consumption of a memory 
device for one or more programs; 
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